REMARKS 



The present remarks are in response to the Office Action dated October 7, 
2005. Claims 1-27 are now pending in this case. No claims have been amended in the 
present response. However, all claims are included herewith for the Examiner's 
convenience. 

The applicants wish to express their appreciation to the Examiner for the 
telephone interview with the applicants' attorney on May 17, 2006. The applicants' 
attorney discussed the inapplicability of prior art references to the claimed invention. 
That inapplicability is discussed in greater detail below. 

The Examiner objected to the disclosure in the specification for failing to 
update the status of an application from which the present application claims priority. 
The applicants have amended the specification to provide the necessary application 
status. 

Claims 1-12 and 19-20 stand rejected under 35 U.S.C. § 102(e) as 
anticipated by U.S. Patent No. 6,154,778 to Koistinen et al. The applicants respectfully 
traverse this rejection and request reconsideration. The Office Action, at page 12, 
responds to the applicants' previous arguments and asserts that Koistinen et al. teaches 
"adjusting of client OoS parameters based on the OoS response received from the 
server" and states that the client trust filter 60 modifies QoS specifications received from 
the server agent 40 according to trustworthiness data for the server agent 40. This is 
incorrect. The client trust filter 60 modifies OoS specifications received from the server 
agent 40 according to trustworthiness data for the server agent 40. However, the OoS 
specifications modified by the client trust filter 40 are, in fact, server OoS specifications 
and not client OoS specifications. The general operation of the client trust filter is 
explained at column 8, lines 31-50. In that section, Koistinen et al. discloses that the 
server agent can intentionally misrepresent the server's OoS behavior under the 
proposed agreement. The "trust function is utilized to modify a declared server 
guarantee to reflect the believed server guarantee." (See column 8, lines 36-38.) Thus, 
the client trust filter 60 essentially discounts the "promises" of the server's OoS 
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specifications. As Koistinen et al. states, "for example, if tine mean availability specified 
in a server guarantee is X, the trust function might reduce the value to a believed value 
of 0.8X." (See column 8, lines 38-41 .) Thus, the client QoS filter alters the promised 
server QoS specifications to reflect the actual expected performance rather than the 
promised performance. Koistinen et al. does not teach or suggest the client trust 
agent 60 altering the client QoS parameters. 

Similarly, Koistinen et al. describes the operation of the server trust filter at 
column 7, line 60 to column 8, line 1 9. As described in that passage, the server trust 
filter "discounts" the client's offered behavior to arrive at an expected client behavior. 
Koistinen et al. does not teach or suggest that the server trust filter alters the server 
QoS parameters. 

In contrast to the teachings of Koistinen et al., claim 1 recites inter alia " 
transmitting a QoS negotiation response to the client QoS negotiator" as well as 
"adjusting client QoS parameters in response to the QoS negotiation response. 
Koistinen et al. does not teach or suggest such alteration in response to the QoS 
negotiation response from the server. Accordingly, claim is allowable over Koistinen for 
at least this reason. Claims 2-4 are also allowable in view of the fact that they depend 
from claim 1 , and further in view of the recitation in each of those claims. 

Claim 5 is directed to a method and recites "receiving a QoS response 
from the server" as well as "adjusting client settings based upon the QoS response." As 
discussed above with respect to claim 1 , the client trust filter does not alter client QoS 
settings based on the QoS response, but "discounts" the value of the offer from the 
server. Accordingly, claim 5 is clearly allowable over Koistinen et al. Claims 6-9 are 
also allowable in view of the fact that they depend from claim 5, and further in view of 
the recitation in each of those claims. 

Claim 10 is directed to a method in which a server receives a QoS request 
originating from a client and constructs and QoS response containing connection 
information and server QoS information. Claim 10 recites "adjusting server parameters 
in response to the QoS request" as well as "transmitting the QoS response to the client." 
As discussed above with respect to claim 1 , Koistinen et al. discloses a server trust filter 
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which alters the client proposal to essentially "discount" the client proposal. The server 
trust filter does not result in the adjustment of server parameters in response to the 
client QoS request. Thus, claim 10 is clearly allowable over Koistinen et al. Claims 1 1 
and 1 2 are also allowable in view of the fact that they depend from claim 1 0, and further 
in view of the recitation in each of those claims. 

With respect to claim 19, Koistinen et al. describes a QoS negotiation 
process, particularly with the use of trust filters to discount the offer received from the 
other party {e.g., the client trust filter discounts the offer from the server). However, 
Koistinen et al. does not describe a generic protocol that operates independent of 
processor architectures, operating systems, network architectures, and transport 
protocols used by the application. (See pending application, page 5.) Claim 19 recites 
inter alia "a generic QoS API for configuring, monitoring, and maintaining the client QoS 
negotiator, the server QoS negotiator, and the generic QoS protocol. Koistinen et al. 
discloses no such process. The generic API is illustrated, by way of example, as the 
API 32 in Figure 1 of the pending application. There is no equivalent structure or 
function disclosed in Koistinen et al. Accordingly, claim 19 is allowable for at least this 
reason. Claims 20-27 are also allowable in view of the fact that they depend from claim 
19, and further in view of the recitation in each of those claims. 

Claims 13-17 stand rejected under 35 U.S.C. § 103(a) as unpatentable 
over Koistinen et al. combined with U.S. Patent Application No. 6,405,251 to Bullard et 
al. The applicants respectfully traverse this rejection and request reconsideration. The 
Qffice Action asserts, at page 7, that Koistinen et al. teaches a client information 
storage unit, a proxy information storage unit, an application profile information storage 
unit, means for storing transport QoS profile information, means for storing per-protocol 
QoS profile information, and means for storing QoS map order information. This is 
incorrect. The sections of Koistinen et al. cited in the Qffice Action describe the 
negotiation process but never disclose a client information storage unit, a proxy 
information storage unit, or an application profile storage unit. Furthermore, Koistinen et 
al. does not teach or suggest any means for storing a per-protocol QoS profile 
information or means for storing QoS map order information. Examples of these 
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specific pieces of data are illustrated in the detailed components of the generic QoS 
protocol shown in Figure 2 of the present invention. Although Figure 4 of Koistinen et 
al. broadly illustrates a utility function, there is no discussion of a per-protocol QoS 
profile nor means for storing such a profile. Furthermore, there is no discussion in 
Koistinen et al. of QoS map order information nor any means for storing such 
information. 

The Qffice Action correctly asserts that Koistinen et al does not teach the 
use of an Internet Control Message Protocol (ICMP) header for transmitting the protocol 
as an out-of-band message and cites Bullard et al. as teaching such a use. However, 
the combination of Koistinen et al. and Bullard et al. does not teach or suggest means 
for storing per-protocol QoS profile information nor means for storing QoS map order 
information, as recited in claim 13. Newton's Telecom Dictionary defines ICMP as a 
"protocol used to handle errors and control messages at the IP layer. {Newton's 
Telecom Dictionary ^ 4th ed. © 1998.) Bullard et al., at column 25, lines 10-26 describes 
precisely that use for ICMP. That is, Bullard et al. describes the use of ICMP for the 
transmission of error messages and describes the error events at column 26, lines 21- 
40. However, Bullard et al. does teach or suggest the use of an ICMP message for the 
transmission of protocol data but only describes its use for its intended purpose of error 
messaging. In contrast, claim 13 recites a non-standard use for the ICMP messaging 
that is unrelated to error processing. This is not taught or suggested by Bullard et al. 
Accordingly, claim 13 is clearly allowable over the combination of Koistinen et al. and 
Bullard et al. Claims 1 4-1 8 are also allowable in view of the fact that they depend from 
claim 13, and further in view of the recitation in each of those claims. 
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In view of the above amendments and remarks, reconsideration of tine 
subject application and its allowance are kindly requested. The applicants have made a 
good faith effort to place all claims in condition for allowance. If questions remain 
regarding the present application, the Examiner is invited to contact the undersigned at 
(206) 628-7640. 

Respectfully submitted, 
Davis Wright Tremaine llp 
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